WIP: By-repository mutex to create issues #7894
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This should fix a possible race condition in
models/issue.go
(#7887) if we deem it necessary to fix; I'm not sure it's much of an issue, however.The idea is to put a lock between
select max(index)
andinsert into issue (index, ....)
, so there's no chance that two simultaneous requests attempt to insert the same index for two separate issues.To make sure it doesn't hurt insert performance, I've used per-repository mutexes with a library I've found at go.chromium.org/luci/common/sync/mutexpool; so there's no lock if two inserts go for different repositories.
As I've said, it's probably not worth fixing; but I figured I'd try anyway. The pattern might be useful for other parts of the code.
One more thing: I couldn't figure out a good way of unit testing this modification. I've been looking around but didn't find anything convincing. Suggestions are welcomed.